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Introduction 

This project addresses the problem of transforming technical documents intended for a 
technical audience into educational materials directed toward segments of the general 
public. In particular it addresses the conversion of technical material into Internet based 
educational materials. A major consideration of the project is the conservation of the 
time of subject matter experts in the organization in recognition of the fact that such 
experts are likely to be more valuable to the organization for purposes other than the 
production of educational outreach. 

Technical organizations produce large numbers of electronic technical documents in 
support of their missions. When such an organization has a need to explain itself to an 
outside audience, the materials in their existing forms are very nearly useless. These 
documents, ranging from proposals to reports to presentations, almost always address 
a technical audience. They presume prior subject matter, and program-related, 
knowledge lacking in the outside audience, and are riddled with acronyms and 
terminology confusing even to insiders. 

Additionally, the format of an outreach document is probably not that of a technical 
report or a proposal or even a slideshow presentation. The technical report is not 
composed with an eye to interesting or educating an audience unfamiliar with its 
material and for similar reasons a proposal is not an appropriate vehicle. Slideshow 
presentations appear to be the most likely documents for reuse, but they cannot 
function as outreach documents without significant modification. The electronic 
slideshow, intended to augment a live presentation, cannot by itself be a substitute for 
the whole presentation. Even if the narration of the original slideshow were supplied, the 
difference in background and educational level between the original audience and the 
outreach audience would prevent the narrated show from being effective. In addition, 
the presentation may contain details of little interest to an outside audience, such as 



budgets and timelines. Even so, these types of material are likely to contain information 
and elements useful in the outreach document. One significant problem therefore is to 
discover protocols or methodologies for automating or facilitating the transformation of 
technical materials into outreach components. 

The task of reworking technical documents cannot proceed without the active 
participation of a content expert. The expert is needed at a minimum to explain the 
overall project being presented as outreach, provide the information missing in the 
documents, and validate the final product. The content expert's time is a valuable 
commodity and the creation of outreach documents is likely to be a task of relatively low 
priority compared with the demands of on-going projects. The second major problem 
then is the effective and convenient use of the content expert's time. 

In the remainder of this paper we will speak as though there were only two people 
involved in the development of the outreach material, a web site developer and a 
subject matter expert. In fact the developer has at least two distinct roles, that of 
designing the web site and that of implementing the design. Likewise the subject matter 
expert is portrayed here in the additional role of the client who has the power to approve 
and sign off on various stages of a project. Other people could well fill these roles and 
others. Also, in what follows, the term 'project' is potentially ambiguous. Sometimes it 
may refer to the website development project and sometimes it may refer to the 
technological project about which the website project reports. Where necessary for 
clarity these two projects will be called the 'website project' and the 'technical project' 
respectively. 


Development Process 

The process is modeled on common software development processes, specialized by 
the orientation to outreach and education on the one hand and web site development on 
the other. The process steps include the development of an overall project plan setting 
forth the functional and non-functional requirements and acceptance criteria; an 
instructional analysis determining learning objectives, capabilities and limitations of the 
audiences (intended students and, if appropriate, teachers) for the products of the 
project; an overall website design including a graphic template and navigation strategy 
accompanied by an illustrative prototype; the creation and revision of the instructional 
website and ancillary materials; and the publication of the site. The process is informed 
by the secondary objective of making effective use of the time of the SME. The 
development of the overall project plan will involve more of the SME's participation than 
any other because the designer, who will translate from the technical language of the 
existing documents to a form understandable by the intended audiences, must herself 
understand the science and technology of the underlying project and the SME must be 
confident of the designer's understanding. The phase of the process by which the 
designer becomes educated should therefore receive special attention. Its objectives 
are not only to educate the designer but to get the SME to buy into the project. The 
designer's education will occur in two parts. First the SME will provide the technical 
documents to the designer for her review. Second the SME will meet with the designer 



to explain the project. Thereafter the interaction between the designer and the SME will 
be conducted asynchronously via the annotation tool described below. The designer 
will create a website, not intended for publication, but which provides a high level sketch 
of the science, technology, aims and benefits of the technical project. By use of the tool 
the SME will correct misunderstandings, provide amplifications, answer questions, and 
approve the high level translation from technical to lay language, all in an asynchronous 
mode. 

The overall-planning phase will also determine the functional and non-functional 
requirements of the project. The requirements will identify the science, technology, 
goals and benefits of the technical project which are to be explained; the audiences, 
such as highschool or college students and teachers; the types of interaction to be 
provided on the site; and the ancillary materials to be made available. The interactions 
include such things as static web pages, simple or complex animations, streaming video 
or audio, self-assessments, interactive tutorials and the like. The ancillary materials may 
include a selection of the technical documents on which the site is based, curriculum 
plans for teachers, assessment instruments or strategies and the like. These aspects of 
the planning phase can also be negotiated via the annotation tool. Thus the planning 
phase will involve the interactive construction of two websites, one outlining the 
designer's understanding of the technical project and one developing the project plan 
and requirements. 

The final aspect of the planning phase involves the recruiting of members of the 
intended audiences who will review the development at stages indicated below. It is 
particularly important to recruit teachers. 

The instructional analysis phase will require the attention of the SME since the 
instructional designer moves from the high level overview of the previous phase to the 
lower level details of the content actually to be conveyed and the SME is needed to 
correct or certify the technical content of the analysis. In this phase the designer 
determines the learning goals and objects for the site, the sequencing of the instruction, 
and a detailed outline of the content. In addition the designer determines the 
background knowledge needed by the audiences to understand the material and 
devises strategies for overcoming any lack. If the website project is to include materials 
for teachers or self-assessments for the audience, the composition of assessment items 
will take place at this time. In addition to the reviews by the SME, the teachers recruited 
during the planning phase should assess the products of the instructional analysis. All of 
this material can be reviewed interactively and asynchronously using the annotation 
tool. 

The production of the website itself requires an overall plan for the look and feel of the 
site: the graphic templates that create a unifying theme and the navigation strategy by 
which the users will traverse the site. After an initial design is approved by the SME, the 
designer will build a small prototype site to be reviewed by the SME and the recruited 
students and teachers. The website project may also involve a separate site for 
teachers and, if so, should be reviewed in a similar fashion. 



All of this leads to the development of the actual website. This is naturally an iterative 
process facilitated by the annotation tool. The SME must certify the correctness of the 
designer's final translation and students and teachers are needed to evaluate the 
usability of the site. Similar interaction is required for the construction of any separate 
site for teachers. 

Finally the sites will be copied to their publication addresses, reviewed and approved by 
the SME. 

The elaboration and validation of this approach is currently being developed as a Ph. D. 
thesis at the University of Central Florida by Terrance Buckner who participated in the 
current project as an instructional designer. 

The Annotation Tool 

Specifications were developed for a software tool to assist in the development of the 
websites. The purpose of the tool is two-fold: 

1. To manage the dialog between the site developer/instructional designer on the one hand 
and the subject matter expert, teachers, and students on the other. 

2. To manage the versioning of the site so that the development process becomes visible 
under review and so that earlier versions and language may be retrieved if desired. 

Dialog between Designer, Expert and Audience 

In most of the phases described above, there was a requirement for an asynchronous 
dialog between the developer and someone else, the subject matter expert or an 
evaluating teacher or student, concerning some document. The designer uses the 
dialog to get confirmations of correctness, corrections, approval, and evaluations. For 
example, one of the designer's aims is a translation of technical concepts into an 
expression that can be understood by the target audience of the site. That translation 
must be validated by the SME. Again, both the overall architecture and its more detailed 
structure must be approved by the SME (in the role of customer) before the designer 
can proceed with detailed development. Later, the SME is needed to ensure that the 
actual expression of the scientific and technical concepts is correct and, again in the 
role of customer, to approve the presentation of the website. Participating teachers and 
students must have a means to comment on the content, structure, and navigation of 
the site. All of these tasks require dialog which is focussed on conceptual, planning, or 
production documents. 

Since a major goal of this project is to make effective use of the time of the SME, our 
intent was to facilitate an asynchronous dialog about the documents of the project, 
whether planning or production. Thereby the need for face-to-face meetings could be 
reduced and the SME would be able to participate at any free moment. Consequently 
we developed a document-centric, web-based annotation tool. The main goals of the 
tool are 



1 . To enable either party to add comments to a dialog about the document in question. 

2. To present a history of the dialog so that the conversation can be reviewed. 

3. To present the document in its current form with the tool so that the document is visibly 
available while the dialog is being reviewed and extended by either party. 

4. To keep the document and the commentary physically separate although they are 
presented together. The annotation tool is not intended as a development environment. The 
designer should be free to use any content creation tools she desires. The designer should not 
have to do anything to the code of a page to make is amenable to the annotation tool. This goal 
also implies that the site can be viewed with or without the tool at any time. 

5. To maintain the tool as context as the user traverses links from page to page. The tool 

will display the dialog history for each new page as it is visited. 


Toward these ends, we 
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developed a tool that presents an HTML page in association 
with two commentary areas. One area presents the history of 
the commentary. The other allows the participant to add 
comments and continue the asynchronous dialog. The 
annotations are kept in a database that associates the 
commentary with the URL of the document. When the tool is 
instructed to retrieve the URL, it retrieves the associated 
commentary (see Figure 1). In addition when the links on the 
page are followed, the target URL is presented within the tool. 
The user of the tool is thus able to view the page and its context 
while reviewing the development dialogs associated with the 
site. 


Figure 1 : Subject web page on the 
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Versioning 


One natural result of the dialogs we are envisioning is that changes will be made to the 
web page. When the changes are small the document is in some sense the same 
document. But when major changes are installed we have a new version of the 
document. The identification of what counts as a new version should be left up to the 
decision of the designer, but the essential fact about a new version is that the old 
version should be kept available in case the old version turns out to be preferable, in 
case there is something useful on the page that might be retrieved in the future, or in 
case the sequence of pages is needed to provide a context for the dialog preserved 
about the page. The ability to create and retrieve versions is also desirable when a 
choice is to be made among several alternatives. It is desirable to be able to view 
alternatives and navigate back and forth between them. 


Consequently we have added a versioning capability to the requirements of the 
annotation tool. One version of a page is always identified as the current version and is 
available at the website. Other versions are stored in the database. The designer uses 
the tool to upload a new web page to the site and designate it as a new version or a 




minor change of an existing page or as a new page. To view another version, the tool 
retrieves the appropriate page from the database. 

The addition of versioning adds complexity to the status of the stored comments 
concerning a page. Each version of the page may have associated comments, but 
comments on other versions may be relevant as well. Therefore the user has a choice 
of viewing the comments which apply to the current version only or to view all 
comments which apply to any version of the page. 

The development of the annotation tool is currently the subject of the Master's project of 
Venkat Varkala at Old Dominion University. 

Conclusion 

We have developed a process for the transformation of technical materials into 
educational websites. We have also developed a tool which supports interactive 
asynchronous dialog about and versioning of the web pages in the development effort. 
The tool can be used in all phases of the project: planning, instructional analysis and 
development. In developing the tool, we have come to realize that in future releases the 
principle of versioning should be applied to sets of related pages rather than to single 
pages. 



